-
Notifications
You must be signed in to change notification settings - Fork 2.3k
refactor(crashlytics): migrate to TypeScript. #8814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
mikehardy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is still a bit shocking to see typescript happening, in the meta sense. Amazing.
Two thoughts - one about shipping all source and one about common tsconfig, I'd class those as meaningful but also easy for a think + fix. Curious what you think on them
Otherwise a +1
| "files": [ | ||
| "lib/modular", | ||
| "dist", | ||
| "!**/__tests__", | ||
| "!**/__fixtures__", | ||
| "!**/__mocks__" | ||
| ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In an open-source context, with a semi-frequent need for "patch-package" I was semi-frequently annoyed when typescript packages didn't ship with all the source needed to recreate the build after doing a yarn inside their module inside node_modules
Is there any reason not to include all the source files? It appears some are missing in the event someone wanted to patch the typescript and transpile it post-install vs patching the generated blobbage
"include": ["lib/**/*", "../app/lib/internal/global.d.ts"],
| @@ -0,0 +1,40 @@ | |||
| { | |||
| "compilerOptions": { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this appears to be 100% boilerplate, any reason not to have a common definition in app and use extends to centralize management of these configs?
Description
Related issues
Release Summary
Checklist
AndroidiOSOther(macOS, web)e2etests added or updated inpackages/\*\*/e2ejesttests added or updated inpackages/\*\*/__tests__Test Plan
Think
react-native-firebaseis great? Please consider supporting the project with any of the below:React Native FirebaseandInvertaseon Twitter